Subject: Minor comments noted in the review draft

From: "John E. Fetvedt (tie 444-4366)" <[email-masked]>
Date: Tue, 31 Aug 93 13:51:21 EDT

CIW OSI TP SIG,

     Attached are several comments that I have received on the review
draft of CPI-C 2.0, along with my suggested text changes. I would
appreciate your review of the suggested changes at your earliest
opportunity.

     Cheers.

John Fetvedt
     CIW OSI TP SIG coordinator

----------------------------- Referenced Note ---------------------------

-------------------------------------------------------------------------

Set_Begin_Transaction - how does it work, especially interaction with
TX on recipient side?

                    ------------------------------

     The recipient needs two pieces of information:

       -  Extract_Transaction_Control (a CPI-C call) - to determine
          whether the conversation is chained or unchained.

===>      We need to add this call to CPI-C. (I will work with Debbie
===>      to create the appropriate call description.)

       -  tx_info (a TX call) - to determine whether or not it is in a
          transaction following successful completion of an Accept or
          Accept_Incoming call.

          This is not a CPI-C call because it goes to the TM, not the
          CRM.

===>      Clarifying text could probably be added to the CPI-C spec.
===>      Suggestions would be appreciated.

-------------------------------------------------------------------------

Begin_Implicit mapping - when program issues call, a begin
transaction PDU is generated.

                    ------------------------------

     Yes, this needs to be shown in the mapping.

     Specific changes include:

===> 1. Add TP-BEGIN-TRANSACTION req to the OSI TP Service column of
===>    Table 17 in Appendix D on pages 296-297 for the following calls:

===>    - CMCFM
===>    - CMINCL
===>    - CMPREP
===>    - CMPTR
===>    - CMRCV
===>    - CMSEND
===>    - CMSERR

===> 2. Add the appropriate mapping to tables 20, 24, 25, 26, 28, 29
===>    and 30. I will work with Debbie to accomplish these updates.

-------------------------------------------------------------------------

When remote program rejects conversation with data, how
does local program extract initialization data?

                    ------------------------------

     The local program gets a control_information value of
     cm_allocate_rejected_with_data and it them does an
     Extract_Incoming_Initialization_data call to get it.
     the Local application will get the cm_deallocated_abend return
     code on the next CPI-C call.

     Specific changes include:

===> 1. Add the following note to the mapping for TP-BEGIN-DIALOGUE
===>    confirm (if: Result = rejected(user) and User_Data is present)
===>    in table 33 in Appendix D on page 307:

===>    "Note: A cm_deallocated_abend return code will be returned to
===>     the next CPI-C call following receipt of a
===>     control_information_received value of
===>     cm_allocate_rejected_with_data.

-------------------------------------------------------------------------

Order of control info returned

                    ------------------------------

     Specific changes include

===> 1. The following note should be added to all calls that return the
===>    control_information_received parameter:

===>    "Note: When more than one piece of control information is
===>     available to be returned to the application, it will be returned
===>     in the following order on multiple calls:
===>        1st - cm_allocate_confirmed, cm_allocate_confirmed_with_data,
===>                or cm_allocate_rejected_with_data
===>        2nd - cm_req_to_send_received
===>        3rd - cm_no_control_info_received

-------------------------------------------------------------------------

Mapping of implicit confirmation of acceptance of the conversation
to OSI TP - the Begin_Dialogue response is generated.

                    ------------------------------

     Yes, this needs to be shown in the mapping.

     Specific changes include:

===> 1. Add TP-BEGIN-DIALOGUE cnf to the OSI TP Service column of Table
===>    17 in Appendix D on pages 296-297 for the following calls:

===>    - CMCFM
===>    - CMDEAL
===>    - CMRCV
===>    - CMSEND
===>    - CMSERR

===> 2. Add the appropriate mapping to tables 20, 22, 28, 29 and 30.
===>    I will work with Debbie to accomplish these updates.

-------------------------------------------------------------------------

Deallocate(sync_level). If Commit fails, is conversation
reset in OSI TP? in LU 6.2?

                    ------------------------------

     No to both.

     Specific changes include:

===> 1. Change the last sentence under the second bullet in section
===>    4.14.3 on page 112 to read:

===>    "If the conversation was initialized during the transaction, the
===>     conversation returns to the state it was in following
===>     conversation establishment."

-------------------------------------------------------------------------

Names and OIDs - description needed

                    ------------------------------

     The format of an OID and a Distinguished Name is described in Usage
     Note 2 under the Extract_Application_Context_Name, Set_AE_Qualifier,
     Set_AP_Title, and Set_Application_Context_Name calls.

     If additional description is required, I am open to suggestions for
     text to be included in Appendix A.

-------------------------------------------------------------------------

Initialization data length - I/O parm?

                    ------------------------------

     Yes, I agree in principle. However, please refer to the following
     change.

     Specific changes include:

===> 1. Edit the note following the description of the
===>    initialization_data_received_length in section 4.21.2 on page
===>    126 to read:

===>    "Note: Unless return_code is set to either cm_ok or
===>     cm_program_parameter_check, the value of
===>     initialization_data_received_length is not meaningful. When
===>     the reason for the cm_program_parameter_check return code is
===>     because initialization_data_length specified a value that was
===>     less than the length of the initialization_data, the actual
===>     length of the initialization_data will be returned in
===>     initialization_data_received_length."

-------------------------------------------------------------------------

Conversion of T61strings

                    ------------------------------

     T61Strings will have to be converted just the same as 01134 and
     00640 character strings. However, in the case of OSI TP, they
     will be converted to the transfer syntax rather than specifically
     to EBCDIC.

     Specific changes include:

===> 1. Split the second paragraph in section 2.8.2 on page 27 following
===>    the second sentence; between "... non-EBCDIC systems." and "This
===>    means ...".

===> 2. Add the following paragraph in section 2.8.2 on page 27 following
===>    the new second paragraph (i.e. between the paragraphs created by
===>    the split):

===>    "When the OSI TP CRM is used, the transfer syntax is negotiated
===>     by the underlying support. CPI Communications automatically
===>     converts these characteristics to the transfer syntax when they
===>     are used as parameters on CPI Communications calls."

===> 3. Delete the note at the end of section 2.8.2 on page 27.

===> 4. Edit the second sentence of note 3 in Appendix A on page 260 to
===>    read:

===>    "When appropriate, CPI Communications automatically converts
===>     these fields to the correct format, i.e. EBCDIC on LU 6.2 and
===>     the negotiated transfer syntax on OSI TP, when they are used
===>     as input parameters on CPI Communications calls."

===> 5. Delete the note at the end of note 3 in Appendix A on page 260.

-------------------------------------------------------------------------

See table 13 on p. 281, States and Transitions for Protected
Conversations (X/Open TX):
What state should a program go to when it issues Commit in the Prepared
state?  The partner may have been in Sync_Point, S_P_Send, or
S_P_Deallocate state when it issued Commit.  Consequently the partner
will be in Receive, Send, or Reset state when its Commit completes.

                    ------------------------------

     Yes, you are right. We need a note to indicate that it may go to
     state 1, 3, or 4 depending on whether or not a Prepare_To_Receive
     or a Deferred_Deallocate call was previously issued.

     Specific changes include:

===> 1. Change the "4" for the tx_commit call (ok,cop,com) in Appendix
===>    C on page 287 to "note 1".

===> 2. Add the following note to the end of table 15 in Appendix C on
===>    page 287:

===>   "Notes:
===>
===>      1. The conversation goes to state 1, 3 or 4 depending on
===>         whether the local program had previously called
===>         Defer_Deallocate or Prepare_To_Receive.

-------------------------------------------------------------------------

The state table entries for Receive (I and W), Send, and Send_Error need
closer examination for states 11, 12, 13, and 15 (Prepared).
For example, the fact that the superior has issued
Prepare means it can issue Deallocate(A) or Backout.  So if the
subordinate issues Send_Error in Sync_Point state, it could get back db
or bo.  The table shows /.

                    ------------------------------

     We need to discuss this in detail. I believe there may be some
     differences between LU 6.2 and OSI TP in this area that may require
     notes.

-------------------------------------------------------------------------

Shouldn't the default value of prepare_data_permitted set by Accept_* or
Initialize_for_Incoming be not applicable?

                    ------------------------------

     Yes, I agree it should be changed.

     Specific changes include:

===> 1. Change the prepare_data_permitted row of Table 3 on page 25 to
===>    contain "Not applicable" in the Accept_Conversation,
===>    Initialize_for_Incoming, and Accept_Incoming columns.

-------------------------------------------------------------------------

     Other specific changes include:

===> 1. Add a CM_PROGRAM_STATE_CHECK to Set_Initialization_Data to
===>    section 4.52.2 on page 208:

===>    "CM_PROGRAM_STATE_CHECK
===>       This value indicates that the conversation was not in
===>       Initialize, Initialize_Incoming, or Receive state.

===> 2. Change the maximum length on initialization data from 10240
===>    to 10000 in section 4.52.2 on page 208

-------------------------------------------------------------------------

There are some words needed to describe the setting of
deallocate_type when unchained transactions are being used.
I presume the same is true for send_type and prepare_to_receive-type.

                    ------------------------------

     Yes, I agree.

     Specific changes include:

===> 1. Add "and transaction_control is set to cm_chained_transactions."
===>    to the third bullet under cm_program_parameter_check in section
===>    4.49.3 on page 202.

===> 2. Change the second sentence of Usage Note 2 in section 4.49.4 on
===>    page 202 to "This deallocate_type value cannot be used for
===>    conversations with transaction_control set to
===>    cm_chained_transactions with sync_level set to cm_sync_point or
===>    cm_sync_point_no_confirm."

-------------------------------------------------------------------------

Prepare is not allowed if the program is not the superior.  Does it make
sense to allow a subordinate program to issue Set_Prepare_Data_Permitted?

                    ------------------------------

     No, it does not make sense.

     Specific changes include:

===> 1. Add "The subordinate program on the conversation cannot issue a
===>    Set_Prepare_Data_Permitted (CMSPDP) call." following the first
===>    paragraph in section 4.56 on page 216.

-------------------------------------------------------------------------

If a program is using unchained transactions and is between transactions,
a Deallocate of type CM_DEALLOCATE_SYNC_LEVEL will be functioning as

       Deallocate (CONFIRM) if sync_level is CM_SYNC_POINT or

       Deallocate (FLUSH)   if sync_level is CM_SYNC_POINT_NO_CONFIRM

                    ------------------------------

     Specific changes include:

===> 1. Add the clause "and transaction_control is set to either
===>    cm_chained_transactions or cm_unchained_transactions and the
===>    application is currently involved in a transaction," following
===>    the first comma in the first sentence of the third bullet under
===>    Usage Note 1 in section 4.49.4 on page 202.

===> 2. Add a fourth bullet to Usage Note 1 in section 4.49.4 on page
===>    202.

===>    "If sync_level is set to cm_sync_point or
===>     cm_sync_point_no_confirm and transaction_control is set to
===>     cm_unchained_transactions and the application is currently
===>     between transactions, a Deallocate of type
===>     cm_deallocate_sync_level will be functioning as:

===>          Deallocate (CONFIRM) if sync_level is CM_SYNC_POINT

===>          Deallocate (FLUSH) if sync_level is CM_SYNC_POINT_NO_CONFIRM

-------------------------------------------------------------------------

p.41...Need to get a better example than the network
       management example just above section 2.13.6.
       Should make it into an example for Chap. 3 and
       refer to it in chap. 2.  The new chap. 3 example
       should show flows for unchained transactions
       and have a note at the bottom that tells what
       would be different if chained transactions were
       used instead.

                    ------------------------------

     I agree and am willing to work with Debbie to review proposed text.

-------------------------------------------------------------------------

p.98...For CM_ALLOCATE_REJECTED_WITH_DATA, if you get this, what
       return code to you get on OSI TP for this value?  In LU 6.2,
       you'd get a DEALLOCATE_ABEND return code, but if you get
       DEALLOCATE_ABEND, you can't issue Extract_Initialization_Data
       because the conversation is deallocated and the conversation
       ID is gone.  How does it work for OSI TP?

                    ------------------------------

     Specific changes include:

===> 1. Add "This value will be returned with a return_code of cm_ok; the
===>    application will receive the return_code value of
===>    cm_deallocated_abend on the next call on the conversation."
===>    following cm_allocate_rejected_with_data under
===>    control_information_received in section 4.9.2 on page 98.

===> 2. Add "This value will be returned with a return_code of cm_ok; the
===>    application will receive the return_code value of
===>    cm_deallocated_abend on the next call on the conversation."
===>    following cm_allocate_rejected_with_data under
===>    control_information_received in section 4.34.2 on page 156.

===> 3. Add "This value will be returned with a return_code of cm_ok; the
===>    application will receive the return_code value of
===>    cm_deallocated_abend on the next call on the conversation."
===>    following cm_allocate_rejected_with_data under
===>    control_information_received in section 4.37.2 on page 168.

===> 4. Add "This value will be returned with a return_code of cm_ok; the
===>    application will receive the return_code value of
===>    cm_deallocated_abend on the next call on the conversation."
===>    following cm_allocate_rejected_with_data under
===>    control_information_received in section 4.38.2 on page 174.

===> 5. Add "This value will be returned with a return_code of cm_ok; the
===>    application will receive the return_code value of
===>    cm_deallocated_abend on the next call on the conversation."
===>    following cm_allocate_rejected_with_data under
===>    control_information_received in section 4.68.2 on page 242.

-------------------------------------------------------------------------

p.113...1st (only) usage note...This says CMDFDE works the same
        as Deallocate(sync_point or SPNC) but it doesn't.  Need
        to rewrite this so it's true.

                    ------------------------------

     Specific changes include:

===> 1. Add ", except that it may be called from Send state at any time
===>    during the current transaction and does not immediately
===>    invalidate the conversation_id." to the end of Usage Note 1 in
===>    section 4.14.4 on page 113.

-------------------------------------------------------------------------

p.141...What happens if you issue CMINCL when NOT in transaction?
        Or what happens if the branch is in CHAINED transaction?
        What if the sub is already in this transaction and you
        issue the call again?

                    ------------------------------

     Specific changes include:

===> 1. Add the following new bullets under cm_program_parameter_check
===>    under return_code in section 4.29.2 on page 141:

===>    "-  The transaction_control is cm_chained_transactions."

===> 2. Add the following new bullets under cm_program_state_check under
===>    return_code in section 4.29.2 on page 141:

===>    "-  The program is not currently involved in a transaction.
===>     -  The program has already issued Include_Partner_In_Transaction
===>        for the current transaction."

-------------------------------------------------------------------------

p.254...Why were some special characters fro T61string added to
        CPIC and some left out?  Is 4A really left bracket?
        Thought brackets weren't defined in EBCDIC set 00650?
        This will cause conversion problems...so need a note
        saying that TP name for LU 6.2 should use char. set
        00640.  Conversion routines are only defined now for
        00640 set.

                    ------------------------------

     Specific changes include:

===> 1. Add "TP_Name" to the list of characteristics identified in the
===>    note under note 4 in Appendix A on page 260.

-------------------------------------------------------------------------

p.41...Section 2.13.6...Add a sentence to end of 1st paragraph saying
       what remote program finds out thru new Extract_Trans_Control
       call.

                    ------------------------------

     Specific changes include:

===> 1. Add a paragraph following the first paragraph in section 2.13.5
===>    on page 41.

===>    "The remote program may determine whether chained or unchained
===>     transactions are being used by issuing an
===>     Extract_Transaction_Control (CMETC) call.

-------------------------------------------------------------------------

p.270...CM_RESOURCE_FAILURE_RETRY...2nd paragraph.  Not sure what
        this par. means; need to clarify.

                    ------------------------------

     I don't know what it was trying to say either.

     Specific changes include:

===> 1. Delete the 2nd paragraph under CM_RESOURCE_FAILURE_RETRY in
===>    Appendix B on page 270.

-------------------------------------------------------------------------